Comments about the Review article in Nature: Programming languages and compiler design for realistic hardware

Following is a discussion about this Review/Insight Article in Nature Vol 549 14 September 2017 page 180, by Fredric T.Chong, Diana Franklin & Margret Martonosi

• The text in italics is copied from the article
  
• Immediate followed by some comments
  

In the last paragraph I explain my own opinion.

Introduction

Today's clasical(non-quantum) computers manage massive hardware and software complexity by layering many abstractions and tools.

It is important to realise that the discussion is here about digital computers.
In the next sentence we read:

These layers that connect algorithms to devices are often termed a 'software toolchain' in which one layer feeds into another to form a chain of input-output transformations that can take a program written in a high level language as the first input and produce, in the final output, the low-level machine instructions to execute on specific hardware.

Remember that this is about digital computers. An Quantum Computer does not support machine instructions. The best a QC can do is to generate all the information that the QC can be configurated.
This whole paragraph is about DC's.
THe next paragraph starts with the following sentence.

In contrast to current classical computers, dispite progress on quantum algorithms, quantum computers are in their infancy.

This is a honnest sentence. The real problem is that you first must design a quantum computer and see how they operate. When that is reliable you can devellop the algorithms.

• In the CC environment in its infancy you had to enter the instructions of the program in the memory of the machine manually and after starting, to test and observe if the result in the registers was the identical as what was calculated by hand. Such a type of program is called machine code.
  
• In a second phase Assembly language became available, which is a one to one copy of the program in machine code. In that case get both the instructions in both binary notation and a more readable language, at the level of the internal registers used.
  In Assembly language a program looks like: Store 5 in Reg A. Store 7 in Reg B. Mul Reg A with Reg B. (Result goes in Reg Q) Store Reg Q in Loc 100. To write such a program is still a very cumbersome task.
  
• In the third stage compilers were available. Compilers are the interface between a program written in a human language and the actual instructions. One line of code in a human language normally generates 10 instructions (or much more).
• In a fourth stage operating systems become available.

A QC neither supports the concept of a compiler and operating system.
What you can have is some type of hybrid system which is a combination of a digital and a quantum computer. In such a combination the digital machine tells each cycle what the quantum machine has to do. When the QM is finished the DM reads out the results and prepares the QM for the next cycle.
In the case of a QC simulator this is different because such a simulation is performed on a Classical computer.

The current state of art in the QC world seems to me as if you are already developping algorithms using a toolbox of which the actual tools, still, are on the drawing board.

In some ways, their state of the art is analogous to 1950s era classical computers.

However there is one big difference. From a logical, mathematical point a Classical Computer is simple. The problem is building one. As such from an architerural point of view there is not much difference between a CC in 1950 and a CC in 2000. From a logical, mathematical point a Quantum Computer is difficult. Besides that there are many more physical problems in their design.

Current qc's can support very view bits, making every quantum bit count.

The limitation in a CC in the 1950's was 64K memory of each 16 bits.

Because QC is so sensitive to storage and execution efficiency, the temptation is to revert to explicit, low level programming approaches akin to the assembly code used in early classical computers.

Both the name classical computer and the comparison is wrong. Any comparison between a QC and DC is tricky because there way of working is different. A QC is a much more analog device and a DC is a digital (discrete) device and works synchronized based on clock pulses. A DC is an collection of Flip Flop's (bits), and-gates, or-gates which state of each is calculated based on clocks pulses. In a DC, simple speaking, at each clock pulse one assembly level instruction is executed and the state of the whole machines changes accordingly, in a well organized, controlled, manner.
In a QC there is no clock pulse and the state of the system changes continuously. In that sense a QC operates much more like an old fashioned radio which is build out of vacume tubes, transistors, resistors, capacitors. An even better comparisson is with an analog computer.
See for example: https://en.wikipedia.org/wiki/Vacuum_tube

Quantum toolflow challenges

A compiler (in the DC environment) transforms high-level language to assembly language for a particular architecture.

That is 100% correct. Very often you need a different compiler for each architecture i.e Intel processor.

In these cases the developper uses a programming language called a hardware description language.

Such a language is much more company/product related, because you must realy specify something that can be build.
This is like specifying a car which should be able to accelerate going from 0 to 100 km in 20 seconds using less than x amount of gasoline.

However the design languages used for hardware synthesis are much more detailed than high-level languages.

That is what seems logical.
See next sentence.

QC shares characteristics with both design models.

I doubt this, based on a clear difference between what a DC is versus what a QC is.
A second important issue is are we discussing of how the manufacturer of a QC works versus how its customers operate.
The manufacturer is generally speaking designing, building and testing new QC hardware. Its customers are using existing hardware. The tools used by the customer is a subset of the tools used by the manufacturer. The customer does not need a hardware description language.

Almost all models of quantum computation require classical control.

I expect they mean: "Almost all models of quantum computation require digital control."
What this means is that for example shor's algorithm can not be computed in full on a QC. See for example page 189 in Nature in the article: Post Quantum cryptography.

This is because it would be difficult to achieve reliable measurement and fault-tolerant computation with error-prone quantum devices if there were no way to sequence operations reliably and to make error-correction decisions.

This sentence, because it is no clear, is confusing. What you need is what the implications are related to, for example, shor's algorithm, which requires intermediate readout of the qubit registers.

Consequently, all known software toolchains assume a 'quantum co processor' model.

That I expect is true, but the reason is different. I expect you cannot really program a QC in the same way as you can program a DC.

Although several variations exist, most available tools support the QASM quantum assembly language, a common language among quantum software toolchains, using it to specify instructions for quantum co-processor (the Scaffold QC tools are available at https://github.com/epiqc/ScaffCC

This links discusses 10 "Built in Quantum Applications". #10 is Shor's algorithm. The question is to what extend this application actual has been tested on a real QC.

Table 1 shows some differences between QC and classical computing that affect the toolchain.

One central building block is the Quantum Compiler. This block is a part of the Digital Computer. Below that block there should be a control block (The same as under the Classical compiler). The function of that block is to control the communication between the digital part (using bits and bytes) and the quantum part (using qubits, superposition and entanglement).

First, although algorithms may be written for varying problem sizes, in order to minimize space and time requirements, the final QC compilation step targets a specific problem and hardware configuration.

The final output of QC compilation is some type of "Configuration recipe" or Configuration file, which is QC dependent.

This allows the compiler maximum knowledge of the complete execution of the program.

This sentence needs much more difficult.

Second, quantum computers are very unreliable, so error-correction techniques are a major algorithm design constraint.

Generally speaking each problem requires a specific algorithm. Each algorithm inturn requires a different configuration. The final design of such a configuration should not bother about error-correction.
One strategy is to implement the solution redundant (twice). But that is horrible.

there is a chasm between the resourses available today and the programs being designed for future quantum computers. Third

This issue is not very important.

Commercially available hardware has so few qubits that the problem sizes supported do not expose bugs in the code.

This sentence only makes sense when is meant: bugs in the configuration.

Exposing physical properties

All QC systems must adhere to the 'no cloning' theorem, which says that qubit state cannot be copied.

IMO what you can not do is to copy a single qubit and claim that the state of the two qubits are identical.
However what is also tricky is to perform an exclusive or on two qubits and store the result in a third qubit.

Therefore, any QC software with qubit copies is invalid.

The toolbox of the Configuration software should contain the necesary constraints to prohibit this.

The combination of state fragility and the no cloning theorem makes error correction much more important in a QC than in classical computing.

A DC from an user point of view does not have error correction. When there are errors they are software related.
The no cloning theorem should be no issue when executing a QC run.
The fragility of the hardware of a QC is the worst problem. This problem requires to perform QC application multiple times and observe each time the results. When the result is always the same you are okay. When this is not the case you are in limbo.

Although errors make communication and holding state costly, the vast parallelism in computing resources help to mitigate this problem.

A current available QC's do not have much computing resources ?

Supporting algorithm analysis and debugging

As a result of this exponentially complex state, only the smallest of quantum programs can be executed on a physical machine or even simulated.

What can be executed on a physical machine depents on the hardware (# of Q gates) available. If the configuration needs more than available, the application has to be scaled down.
Simulation on a DC in general does not have this issue.

QC software toolchains do not perform full system simulation.

That is strange. In principle it should be possible to simulate any configuration on a DC. Such a simulation should also indicate what type of errors can be expected when running the same configuration on a real QC.

Programming languages

Many people hope that quantum programming languages will aid in the discovery of new quantum algorithms.

New quantum algorithms (i.e. a sequence of quantum operations) completely depend on new quantum operations (gates).

At this point, however most QC algorithm designers work at a more mathematical level and do not consider the programming language (pl) to be the limiting factor in designing new algorithms.

The pl is at this level of no importance. First you must design and build new hardware i.e. quantum hardware. The second step is to implement this new QH into a QC and test it if the results are as expected. The third step is to implement this new hardware into the toolbox of the pl.

Our experience is that implementing a QA - that is, transforming them from a mathematical description in a scientific paper into an executable implementation - can be complex and error-prone.

See also Reflection 3 - Software development DC versus QC

Compilers

Compilers are software programs that translate an algorithm written in a high-level language into machine language instructions that can be executed step by step on particular hardware.

This is only true for a DC but not for a QC.
At the last line of this section we read:

We now discuss static and dynamic compilation and their relationship to the unique properties of quantum computation

This is a whole new ball game.

The primary advantage of compilation for QC systems, compared to classical analoque (DC systems), is that QC programming models typically offer much more detailed information about program and the data; this extra information allows QC compilers to perform optimizations not available to classical compilers.

This is sales talk. The sentence IMO is completely out of touch with the DC reality. DC systems do not need this type of optimization.

In addition, QC hardware provides much more parallelism than classical hardware - some designs propose that the same operation can be applied to every qubit at the same time.

In a one processor DC 'nothing' goes in parallel. This is not totally true. In a one processor DC sometimes certain instructions can be performed in parallel dependent about the internal level of sophistication used. That means often a add, subtract, multiply and divide operation can be performed in parallel assuming that the inputs of one operation do not depent on the output of an other operation.
In a QC environment all qubits are operating in parallel. That is the whole idea behind the speedup of a QC versus a DC.
See also page 206 of the article: Quantum computational supremacy.

Static compilation

Dynamnic compilation

Classical co-processing

With the growing importance of hybrid algorithms that use both quantum and classical processing, such as variational eigensolver, representing and coordinating these computations is an important task.

Shor's algorithm also requires such an approach. The issue is that between cycles the configuration of the QC has to be addapted.
The rest of this paragragh gives a good indication how complex a QC is. Part of the problems are related with the communication between the two systems.

Debugging and assertions

Outlook

This revolution, however, will depend heavily on the software toolchains that will bridge the gap between algorithms and physical machines.

The biggest problem with QC's is to what extend the predicted outcome of any configuration is in agreement with the actual outcome.
On a DC this is always the case. This says nothing if the program is correct. Generally speaking when you perform the same program twice you always get the same. This does not have to be on a QC. When this is not the case the implementation of algorithms on a QC becomes tricky.

Reflection 1 - Programming any QC

Before you want to program a QC you must a problem at hand and know the algorithm (using the special building blocks of the QC) how to solve the problem. The next step is to implement the building blocks, to test the application and when it gives the expected result you are finished or almost finished.
The next step is to make the problem larger. When you are in that phase it becomes handy if you can automate this process and use some type of programming tool or software language to do this.

Reflection 2 - Comparing programming DC versus QC

In a Digital Computer you can perform loops and arrays. The practical implication is that you can describe a function based on a parameter i which uses the arrays X(),Y() and Z(). This function has only to implemented once.
For example: For i=1 to n: z(i)=x(i)+y(i): next i
In a QC such a functionality does not exist, because all operations have to be performed simultaneous.
To solve that each use of any function has to be implemented separately.

Reflection 3 - Software development DC versus QC

Suppose you want to solve a problem on a DC. What is involved.

• First you define the problem in a more general sense. This includes a certain number of test cases.
• Next you specify the problem in mathematical sense. In many cases this is an algorithm in the form of a flowchart which defines all the necessary details.
• Next you select a programming language and you write your program.
• Next you test your program using your test cases.
• In many cases writing a program first means to define, write and test certain subroutines. The advantage is that testing a the final program based on subroutines will be faster. Also subroutines can be reused which will be an advantage for other applications.

My experience with software development is that roughly the first 90% of software takes 10% of time and the final 10% of software takes 90% of time.

Reflection 4 - Software in a hybrid environment

Accordingly to the current state of art a Quantum Computer is not considered a stand alone system but is an integrated system. A better name for such a system is an Hybrid System which means an integrated system of both a Digital Computer and a Quantum Computer. The Digital Computer is in control of the Hybrid System.
Within such a system the title of this article is rather misleading i.e. "Programming languages and compiler design for realistic hardware"
The issue is to what extend can the QC can be programmed. To be more specific: to what extend can the configuration of the QC really be changed by commands from the DC. There are two types of answers:

• No. That means the QC configuration has to be done before you press the RUN button on the QC.
• A little. That means that by means of certain commands you can modify the configuration of the QC. The problem is the more you can modify that this could interfer with the actual operation of the QC. What ever, what you can modify is very QC design dependent.

At the bottom line, what this means, that you cannot actual program, an QC. You can only configure a QC.

Reflection 5 - Overall evaluation of the article

The overall impression of the article is that there are many issues in relation to software in the QC environment. The problem is that the article discusses what is better called an hybrid system which is in this case a combination of a DC and a QC system. The article discusses software in the QC environment while in reality you can only program a DC and not a QC. What that means is that the concept of higher level language is irrelevant for the QC part.
A QC requires configuring. That issue is not discussed.

Back to my home page Index
Back to Nature comments Nature Index